1. Field of the Invention
The application relates to a method and a related communication device used in a wireless communication system and related communication device, and more particularly, to a method of handling signaling congestion and a related communication device in a wireless communication system with machine type communication.
2. Description of the Prior Art
Machine to Machine (M2M) communication (also referred to as “machine-type communications” or “MTC”) may be used in a variety of areas. In the area of security, M2M communication may be used in surveillance systems, in backup of telephone landlines, in the control of physical accesses (e.g. to buildings), and in car/driver security. In the area of tracking and tracing, M2M communication may be used for fleet management, order management, Pay As You Drive (PAYD) applications, asset tracking, navigation, traffic information applications, road tolling, traffic optimization, and steering. In the area of payment systems, M2M communication may be used in point of sales, vending machines, customer loyalty applications, and gaming machines. In healthcare, M2M communication may be used for remotely monitoring vital signs, supporting the elderly or handicapped, in web access telemedicine points, and in remote diagnostics. In the area of remote maintenance/control, M2M communication may be used in programmable logic controllers (PLCs), sensors, lighting, pumps, valves, elevator control, vending machine control, and vehicle diagnostics. In the area of metering, M2M communication may be used in applications related to power, gas, water, heating, grid control, and industrial metering. Additionally, M2M communication based on machine type communication (MTC) technology may be used in areas such as customer service.
Depending on its implementation, M2M communication may be different from some current communication models. For example, M2M communication may involve new or different market scenarios. M2M communications may also differ from some current technologies in that M2M communication may involve a large number of wireless transmit/receive units (WTRUs), and/or may involve very little traffic per WTRU. Additionally, relative to some current technologies, M2M communication may involve lower costs and less effort to deploy.
M2M communications may take advantage of deployed wireless networks based on Third Generation Partnership Project (3GPP) technologies such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Long Term Evolution Advanced (LTE-Advanced), and/or other technologies such as WiMAX (Worldwide Interoperability for Microwave Access) or those developed by the Institute for Institute of Electrical and Electronics Engineers (IEEE) and 3GPP2. M2M communications may use networks based on these technologies to deliver business solutions in a cost-effective manner. In a circumstance involving ubiquitous deployment of wireless networks, the availability of the wireless networks may facilitate and/or encourage the deployment and use of M2M WTRUs. Additionally, further enhancements to these technologies may provide additional opportunities for the deployment of M2M-based solutions.
Referring to 3GPP TS 22.368, the requirements related to MTC Device triggering operation include the following: the network shall be able to trigger MTC Devices to initiate communication with the MTC Server based on a trigger indication from the MTC Server; a MTC Device shall be able to receive trigger indications from the network and shall establish communication with the MTC Server when receiving the trigger indication. The MTC Feature Time Controlled is intended for use with MTC devices and/or MTC Applications that are delay tolerant and can send or receive data only during defined time intervals and avoid unnecessary signaling outside these defined time intervals. The network operator may allow such MTC devices and/or MTC Applications to send/receive data and signaling outside of these defined time intervals but charge differently for such traffic. For the Time Controlled MTC Feature:                The network operator shall be able to reject access requests per MTC Device (e.g. attach to the network or set up a data connection) outside a defined access grant time interval.        The network operator shall be able to allow access (e.g. attach to the network or set up a data connection) outside a defined access grant time interval and charge this differently.        The network shall reject access requests per MTC Device (e.g. attach to the network or set up a data connection) during a defined forbidden time interval (e.g. to allow maintenance of a MTC Server).        The local network shall be able to alter the access grant time interval based on local criteria (e.g. daily traffic load, time zones). The forbidden time interval shall not be altered.        
In the prior art, the solutions of time-controlled mechanisms, including network access control by the PLMN and randomized triggering of time-controlled MTC operations, for MTC in wireless network are not taken signaling congestion/overload control into account. This may cause some issues as described below. The possible solutions to tackle these issues shall not add extra signalling burden to the network.
The triggering operation is randomized for the time-controlled MTC devices by MTC devices or the network including MTC server. However if signaling congested/overloaded situation happens in the network, the triggering operation performing by the MTC devices or the network would make the congested/overloaded situations worse.
A MME (mobility management entity) Load Balancing functionality permits UEs that are entering into an MME Pool Area to be directed to an appropriate MME in a manner that achieves load balancing between MMEs. This is achieved by setting a Weight Factor for each MME, such that the probability of the eNodeB selecting an MME is proportional to its Weight Factor. The Weight Factor is typically set according to the capacity of an MME node relative to other MME nodes. The Weight Factor is sent from the MME to the eNodeB via S1-AP messages (see TS 36.413 [36]). If a HeNB GW is deployed, the Weight Factor is sent from the MME to the HeNB GW.
The major challenge of the machine type communication is simultaneous network access from the massive MTC devices. Even though the network is not congested/overloaded, the load rebalancing function acting on massive MTC devices may induce great volume of signaling overhead, e.g. S1, or RRC release procedures, or TAU procedures.
If the MTC device does not have valid communication window, the new communication window is provided to the MTC device by randomly initiating NAS signaling or application level, which may be outside of communication window. However the network operator may charge differently for sending/receiving data and signaling outside of a defined grant time interval.
The network retrieves grant time interval and forbidden time interval from HLR/HSS (Home Location Register/Home Subscriber Server) where the subscriptions of the MTC devices are stored. The communication window is not stored and would be randomized and configured at SGSN/MME (serving GPRS support node/mobile management entity). If the grant time interval needs to be altered, the SGSN/MME determines the new grant time interval along with new communication window and shall notify HLR/HSS and MTC devices via NAS signaling or application level. The MTC devices are allowed to access network within allotted communication window, otherwise the network can reject accesses. The MTC device can obtain allocated communication window via NAS signaling, e.g. attach or TAU procedure, or application level. Please refer to FIG. 1, which illustrates successful completion of communication task.
In the case of using NAS signaling for updating communication window, if there is no valid communication window, the MTC device might initiate NAS signaling outside of communication window and obtain the communication window from accept or reject message. However there are situations that the MTC devices do not have valid communication windows and need to initiate NAS signaling randomly, which increase signaling overheads as shown in FIG. 2:                e.g1. the altered communication window is not successfully sent to the MTC devices via accept or reject message.        e.g.2. the MTC device is barred by RAN during its allocated communication window.        e.g.3. the MTC device or the network ceases triggering operation due to congestion/overload situation.        e.g.4. the MTC device is forced to detach from the network with network congested cause and a backoff timer before it completes its communication task. In this case, the NAS signaling may be initiated outside of the communication window when the backoff timer is expired if applied.        
The above mentioned situations would result in unpredictable signaling overheads to SGSN/MME. Latter three cases might further jeopardize the network in a congested/overloaded network.